Everything hsc knows about html, it retrieves from a file named hsc.prefs at startup. This file contains information about all tags, entities and icon entites. Additionally, some special attributes are set up there also.
The main advantage of this concept is that it's rather
easy to add new syntax elements. For this task, the hsc tags
<$deftag>, <$defent> and <$deficon> can be used.
It is a serious problem about html that no one can give you competent answer on the question ``Now which tags are part of html?''. On the one hand, there is w3c, which you meanwhile can ignore, on the other hand, there are the developers of popular browsers, which implement whatever they just like.
The hsc.prefs coming with this distribution should support most elements needed for everyday use. This includes full html-2.0-support, tables, client-side image-maps and several elements only used by special browsers.
However, they are currently rather outdated and could need a major rework. This should come with one of the next releases.
PROGDIR:, which is automatically
assigned to the same directory where the hsc binary resides
when hsc is invoked
If it is unable to find hsc.prefs anywhere, it will abort with an error message.
If you want to find out where hsc has read hsc.prefs from, you can use STATUS=VERBOSE when invoking hsc. This will display the preferences used.
This tag defines
a new entity. The (required) attribute NAME declares the
name of the entity, RPLC the character that should be
replaced by this entity if found in the hsc-source and NUM
is the numeric representation of this entity.
<$defent NAME="uuml" RPLC="ΓΌ" NUM="252">
This tag defines
a new icon-entity. The only (required) attribute is NAME
which declares the name of the icon.
<$deficon NAME="mail">
This tag defines
a new tag, and is used quite similar to <$macro>, exept that a
tag-definition requires no macro-text and end-tag to be followed.
<$deftag IMG SRC:uri/x/z/r ALT:string ALIGN:enum("top|bottom|middle") ISMAP:bool WIDTH:string HEIGHT:string>
To fully understand the above line, you might also want to read the sections about attributes and options for tags and macros.
For those, who are not smart enough or simply to lazy, here are some simple examples, which should also work somehow, though some features of hsc might not work:
<$deftag BODY /CLOSE BGCOLOR:string> <$deftag IMG SRC:uri ALT:string ALIGN:string ISMAP:bool>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
Browsers should read that line, obtain the DTD and parse the source according to it. The problem about DTDs: they are written in sgml. And the problem about sgml: It's awful. It's unreadable. It's a pure brain-wanking concept born by some wireheads probably never seriously thinking about using it themselves. Even when there is free code available to sgml-parse text.
As a result, only less browsers did support this. As it was rather easy to write a browser spiting on the sgml-trash, but simply parsing the code ``tag-by-tag'', developers decided to spend more time on making their product more user-friendly than computer-friendly (which really can understand).
These browsers became even more popular when they supported tags certain people liked, but were not part of DTDs. As DTDs were published by w3c, and w3c did not like those tags, they did not made it into DTDs for a long time or even not at all (which I really can understand, too).
This did work for a certain degree until html-2.0. Several people (at least most of the serious w3-authoring people) did prefer to conform to w3c than use the funky-crazy-cool tags of some special browsers, and the funky-crazy-cool people did not care about DTDs or html-validators anyway.
However, after html-2.0, w3c fucked up. They proposed the infamous html-3.0 standard, which was never officially released, and tried to ignore things most browsers did already have implemented (which not all of them were useless crap, I daresay.). After more than a year without any remarkable news from w3c, they finally canceled html-3.0, and instead came out with the pathetic html-0.32.
Nevertheless, many people were very happy about html-0.32, as it finally was a statement after that many things became clear. It became clear that you should not expect anything useful from w3c anymore. It became clear that the browser developers rule. It became clear that no one is going to provide useful DTDs in future, as browser developers are too lazy and incompetent to do so. It became clear that anarchy has broken out for html-specifications.
So, as a conclusion, reasons not to use DTDs but an own format are:Quite unexpected, with html-4.0 this has changed for some extent, as the DTDs are quite readable and well documented. Although it will take them more than this to get back the trust they abused in the recent years, at least it is a little signal suggesting there are some small pieces of brain intact somewhere in this consortium.
There is also a disadvantage of this concept: reading hsc.prefs every time on startup needs an awful lot of time. Usually, processing your main data takes shorter than reading the preferences. You can reduce this time, if you create your own hsc.prefs with all tags and entities you don't need removed. But I recommend to avoid this because you might have to edit your preferences again with the next update of hsc, if any new features have been added.